More Effective Agile
1
アジャイルについての筆者の考えと、この本の特徴を述べている。非常にリアルな経験をもとに書かれている。
メモ
品質・予測可能性・大規模なプロジェクト・数字に現れる改善・規制産業で活用可能か
ほとんどの組織はアジャイルプラクティスの能力に気づけない、うまく実践しないから
良いプラクティスもあれば、微妙なものもある
用途が限られるものを使ってしまっている
他との違い
実践に共通する課題
組織の一部でのみ実践するには
予測可能性のサポート
地理的に分かれているチームでどうするか
2
アジャイルと既存の開発プロセスを対比させ、どう異なるのかを整理している。アジャイルのプラクティスはオールオアナッシングではなく、必要に応じて取捨選択すべきと主張している。いずれにせよ、うまくいっているプロジェクトは「やることをやっている」。アジャイルと非アジャイルの境界を意識するべきだ。
感想
アジャイルと非アジャイルの境界を考えてみるというワークは面白い。何を意識して何はプラクティス通りやれば良さそうなのかを考えることができそうだし、より良いインタフェースを考えることができそうに思ったmactkg.icon
メモ
ウォーターフォール v.s. アジャイル p.9
実際はウォーターフォールではなく、工程による開発
今はシーケンシャルな開発
アジャイル
リリースサイクルは短い
E2Eの開発の大きさが小さい
要求獲得〜設計〜CD〜テスト〜文章化の大きさ
事前に大きくプランニングせずJITする
要求獲得作業をできるだけ少なくする(深さより幅を優先する)
要求の獲得はアジャイル初期と比べて発展している => 13 / 14
事前な設計よりは創発的な設計
アジャイル開発とシーケンシャル開発の比較では、どちらか一方をよいものとし、もう一方をよくないものとする傾向がある。これは公平ではないし、そうしたところで得るものもない。順調に進むプロジェクトは、(中略)管理をきちんと行うことと、顧客とのハイレベルなコラボレーションを重視している。そして、高品質な要求、設計、コーディング、テストに重点的に取り組んでいる。
アジャイルの境界 p.14
ほとんどの組織は、エンドツーエンドのアジリティの実現には至らない。
そこで役立つのが、アジャイルの境界がどこにあるのかを理解しておくことである。
3
いまいちソフトウェア開発との関連は強くわからなかった(特にOODAループ)。 ソフトウェアプロジェクトは、低品質、プロジェクトの遅れ、完全な失敗を含め、多くの課題の要因となっている複雑さにどのように対処するかという問題とずっと戦ってきた。
メモ
不確実性や複雑さを管理するためのフレームワーク
ソフトウェア開発だと複雑か、煩雑になる
煩雑だと思っていたが、複雑だった場合にシーケンシャルに進めると手戻りはすごい。
複雑だと思っていたが、煩雑だった場合は、条件が整理されているだけで理解は深まっている。そんなに痛手ではない。
シーケンシャルなアプローチはリスクがある。mactkg.icon
絶対的な自信があればシーケンシャルで良さそ
OODAループ
アメリカ空軍の大佐が空中戦の結果に不満を抱いて誕生したと書いてあるけど、Wikipediaには朝鮮戦争でアメリカ空軍がなぜ良い成績だったかを調べていてまとめあげたと書いてある mactkg.icon
的より素早く判断を下して、相手の意思決定を無効にしていく
観察 => 方向付け => 意思決定 => 行動 => 観察...という順番が基本。
ショートカットしても良い。素早くやる方が重要で、敵の判断を狂わせたいので
観察
状況・外部情報を観察し、環境とどのように関わるかを考える。OODAではここが最も重要
方向付け
観察と、自分が置かれている状況を結びつける
受け継がれた特性・文化的な伝統・過去の経験などと関連づける
この情報は何を意味するのか?利用可能な選択肢は何か?
盲点を回避したい
意思決定
相手のOODAループを崩すような意思決定をすることが軍隊では多い
例: 打者が速いボールを予測していそうだとすれば、チェンジアップを投げる
行動
やる
「検査と適用」というのがわかりやすい
スクラムも検査と適用が基本
4
コード & フィックス開発
とりあえず書いてみて、動くまでデバッグする
作業の半分以上が欠陥の修正に費やされる
アジャイルでサイクルが短くなっているから、コード&フィックスしてるのか、アジャイルなのか一見見分けがつかない
スクラムから始めよう
予測可能性をサポートしたければ => 20